1. Field of the Invention
Embodiments of the present invention generally relate to HyperText Transfer Protocol (HTTP) Live Streaming (HLS) splicing and, more particularly, to a method and apparatus for performing server-side splicing for live streaming media.
2. Description of the Related Art
HyperText Transfer Protocol (HTTP) Live Streaming (HLS) is an HTTP-based media streaming communications protocol for downloading a media stream onto a client computer. HLS operates by dividing an overall stream of media content into a sequence of small HTTP-based file downloads usually five to ten seconds in duration, each download loading one or more short segments of an overall stream. At the start of the streaming session, HLS client downloads an extended M3U (m3u8) playlist containing an ordered list of media Uniform Resource Identifiers (URIs) and information tags. The playlist is a series of media content segments. Each media content segment is specified by a media URI and the tags that apply to it. An EXTINF tag specifies the duration of the media content segment. Each media URI in a playlist has a unique integer sequence number. The sequence number of a URI is equal to the sequence number of the URI that preceded it plus one. The sequence number of the first URI is equal to the value of the EXT-X-MEDIASEQUENCE tag, which is listed in the m3u8 before any segment URI entry. Typically, a sliding window is maintained in the HLS playlist where one or more segment URI entries are appended to the playlist periodically and one or more segment entries are deleted from the top. When any entry is deleted from the top of the m3u8, the EXT-X-MEDIASEQUENCE is updated to equal the sequence number of the first media segment entry.
A common technique of inserting additional content, typically advertising, into a live media stream is called “splicing”. Splicing involves replacing some of the media content segments in a live media stream with new content. For example, during a live sporting event, such as tennis, the players take breaks between each game or between sets. These breaks in the play are opportunities to present advertising to viewers. More specifically, the breaks may correspond to one or more sequential media content segments being presented to the viewers of the live media stream, and therefore these sequential media content segments can be replaced in the live media stream with advertising. A “splice out” point is the point in the live media stream where the media content stream stops and the advertisement content stream begins, thereby replacing the media content with advertising content in the stream that follows the splice-out point. A “splice-in” point is the point in the stream where streaming of the advertisement segments ends and streaming of the media content segments begins again. Advertisements have playlists similar to the media content. Splicing involves replacing the segment URIs in the HLS playlist (m3u8) that correspond to the media content with the segment URIs that correspond to the advertisement content. The sequence number of the media segment, immediately after the splice-in point, will be different in a spliced playlist if the number of main content segments replaced does not equal the number of advertisement segments inserted. Another complication is that these offsets in sequence numbering may not be the same for different client-target-groups, as these client-target-groups could potentially be served with a different set of advertisements.
It is important to keep the sequence number of the media segment just after the splice-in point unaffected. If the sequence number of the media segment just after the splice-in point is changed, the media splicer will need to remember all such differences that were incurred due to all splicing done so far, even for the advertisements that have been spliced in have moved out of the m3u8's sliding window. Otherwise, if, for example, two media splicers start at different points in time and even if they replace ad breaks with the same set of advertisements, since the second splicer did not process some of the ad breaks that the first splicer had previously processed, it is possible that the sequence numbers in the m3u8, generated from the two splicers, will not match and an HLS client will find a jump or lag in the sequence number when it switches to another server for a stream playback.
One solution is to require the advertisement playlist to contain the same number of URIs as the number of media content entries to be replaced in the m3u8. This causes difficulties in fully utilizing HTTP caching of the advertisement content because the way the advertisement may be broken up is different across different streams. Another solution is to keep the current state of client interactions in a client session cookie, which can then be utilized to create a final m3u8; however, the final m3u8 generated by this technique will not be sharable across different clients and will not be cacheable, thereby not utilizing the full capabilities of HTTP. Another solution is to provide client-side splicing. Here, the media content m3u8 and the advertisement playlist are provided to a client application. The client application will replace main content URIs with advertisement URIs in order to generate an m3u8 consumable by the clients' video-player. This approach requires that the content publishers derive their client applications from a predefined software development kit and will not work when a client is a browser.
Thus, there is a need for a method and apparatus for performing server-side splicing for live streaming media.